Systems and methods for intelligent probe testing

ABSTRACT

Systems and methods are disclosed for testing a processor having at least a first interface. In one embodiment, the method includes configuring, at the processor, a second interface, such that the configured second interface has one or more quality of service parameters representative of the first interface; sending one or more packets through the configured second interface, the one or more packets being representative of another packet received at the first interface; and determining, based on the one or more packets, one or more performance parameters corresponding to the first interface under test.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.10/903,586 now U.S. Pat. No., filed Aug. 2, 2004, entitled “SYSTEMS ANDMETHODS FOR INTELLIGENT PROBE TESTING,” which claims the benefit ofpriority to U.S. provisional application No. 60/491,566, filed Aug. 1,2003, entitled “SYSTEMS AND METHODS FOR INFERRING SERVICES ON ANETWORK,” U.S. provisional application No. 60/577,165, filed Jun. 7,2004, entitled “SYSTEMS AND METHODS FOR INTELLIGENT PROBE TESTING,” andto U.S. Non-Provisional Application No. 10/903,586, filed Aug. 2, 2004,entitled “Systems and methods for intelligent probe testing”, all ofwhich are expressly incorporated by reference herein in their entirety.

BACKGROUND

I. Field of the Invention

The present invention generally relates to communication systems and, inparticular, to systems and methods for testing network systems andprocessors.

II. Background And Material Information

Probes can be used to test a communication network, including any partof the network, such as network nodes, devices, components, interfaces,links, protocols, and the like. For example, in a simple networkconsisting of two routers connected by a communication link (such as anInternet Protocol (IP) network), a probe may be configured at eachrouter to measure various parameters including packet loss, jitter,latency, etc. Each of the probes may be a hardware-type probe, asoftware-type probe, or a combination of the two.

When a network service provider offers network services to a customer,they usually agree on one or more performance or service levels to beprovided by the network. For example, a customer may have two types oftraffic, such as voice traffic and email traffic, each of which mayrequire a different level of service. In this example, the customer mayenter into a Service Level Agreement (SLA) that provides a higher levelof service (e.g., low jitter, low latency, and low packet loss) to voicetraffic, and a lower level of service (e.g., best efforts) to emailtraffic. The network service provider and the customer will then want toknow whether the performance parameters of the SLA are being met. If theservice provider has other SLAs for other customers, the performanceassociated with those other customers will also be of interest.

To that end, probes have typically been deployed to monitor eachcustomer and/or service. Although it may be useful to accurately monitorperformance for every customer, in a complex network environment with avariety of customers and/or services, deploying a probe at/to eachcustomer or service interface is not practical (e.g., it is costprohibitive). Therefore, there is a need to provide a system and methodthat can monitor the performance of customers and/or services withoutrequiring the deployment of a dedicated hardware and/or software probeto each customer location and/or interface.

SUMMARY OF THE INVENTION

The present invention is directed to systems and methods for testingnetwork systems and processors.

Systems and methods consistent with one embodiment of the presentinvention can test a first processor having at least a first interfaceby configuring, at the first processor, a second interface, such thatthe configured second interface has one or more quality of serviceparameters representative of the first interface. Moreover, systems andmethods consistent with one embodiment of the present invention can sendone or more packets through the configured second interface, the one ormore packets being representative of one or more other packets receivedat the first interface. Furthermore, systems and methods consistent withone embodiment of the present invention can determine, based on the oneor more packets, one or more performance parameters corresponding to thefirst interface under test.

Additional features and advantages of various embodiments may berealized and attained by the systems and methods particularly describedin the written description, the appended drawings, and the claims.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory onlyand are not restrictive of the invention, as described. Further featuresand/or variations may be provided in addition to those set forth herein.For example, the present invention may be directed to variouscombinations and subcombinations of the disclosed features and/orcombinations and subcombinations of several further features disclosedbelow in the detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate various embodiments and aspectsof the present invention and, together with the description, explain theprinciples of the invention. In the drawings:

FIG. 1 illustrates an exemplary network environment;

FIG. 2 depicts, in greater detail, a portion of the FIG. 2 networkenvironment;

FIG. 3 is a flowchart showing exemplary steps for determiningperformance using an intelligent test probe;

FIG. 4 illustrates an exemplary system environment;

FIG. 5 is another flowchart showing exemplary steps for determiningperformance using an intelligent test probe;

FIG. 6 illustrates another exemplary network environment;

FIG. 7 illustrates the tunnels of the FIG. 6 network environment;

FIG. 8 depicts loop back tests performed to remove the performancecontributions of the test probe host (referred to as the IntelligentNetwork Element (INE);

FIG. 9 is another flowchart showing exemplary steps for determiningperformance using an intelligent test probe; and

FIG. 10 depicts another exemplary network environment that includes aswitch interfacing a local network.

DETAILED DESCRIPTION

Reference will now be made in detail to embodiments of the invention,examples of which are illustrated in the accompanying drawings anddescribed in the specification. Wherever possible, the same referencenumbers will be used throughout the drawings to refer to the same orlike parts.

FIG. 1 depicts an exemplary network environment 1000 consistent with oneembodiment of the present invention. Referring to FIG. 1, the networkenvironment 1000 includes one or more nodes A-C 1200, 1300, 1302connected by a communication channel (e.g., a network) 1120 to one ormore Intelligent Network Elements (INE) 1170-1171 and a NetworkManagement System (NMS) 1175, all of which will be described in greaterdetail below.

Each of nodes A-C 1200, 1300, 1302 represents a point on the networksuch as a processor, a router, a switch, a gateway, or any othercommunication or data processing device.

Communication channel 1120 may function as a communication network (orlinks) and may include, alone or in any suitable combination atelephony-based network, a local area network (LAN), a wide area network(WAN), a dedicated intranet, the Internet, a wireless network, or a bus.Further, any suitable combination of wired and/or wireless componentsand systems may be incorporated into the communication channels. Theterm “network” means a system of interconnected nodes includingcorresponding links and may include one or more of the componentsdepicted in network environment 1000. As used herein, a connection meansa path, such as a link or a tunnel.

The Intelligent Network Elements (INE) 1171-1170 function to test aninterface (also referred to as the “interface under test”) at a node(e.g., node 1200) by configuring another interface at the node, suchthat the “configured interface” has the same (or similar) quality ofservice (QoS) parameters to the QoS parameters of the interface undertest.

Moreover, one INE 1170 may generate packets and send these packetsthrough the configured interface at node 1200. The packets sent throughthe configured interface may be generated so that they are similar tothe type of packets received at the interface under test. Another INE1171 may function to receive any generated packets. INE 1171 may alsouse the received packets to determine one or more performance parametersfor node 1200, such as latency, jitter, or packet loss. These parametersserve to test the interface under test at node 1200. As a result, theINE intelligently tests an interface at node 1200 by configuring anotherinterface at the same node and sending packets through the otherinterface. If multiple interfaces require testing at node 1200, the INEcan reconfigure the other interface to have the same (or similar) QoSparameters as those other interfaces under test, and can generatepackets that are similar to the packet type received at each interfaceunder test. If multiple nodes are present in network environment 1000,INE 1170 can connect (either virtually or physically) to multiple nodesand test their interfaces. As such, systems and methods consistent withone embodiment of the present invention, reduces (if not eliminates) theneed to have a test probe at each interface and at each node in anetwork.

Moreover, in some embodiments, each of INE 1170 and 1171 may be embodiedto have the features disclosed in U.S. patent application Ser. No.10/845,517, filed May 14, 2004, entitled “SYSTEMS AND METHODS FORINFERRING SERVICES ON A NETWORK,” [Attorney Docket No. 09278-0001] whichis incorporated herein by reference in its entirety. Such features mayinclude participating in a network by, for example, receivinginformation, such as statistics, event information (e.g., networkfailures), and topology information (e.g., interfaces, links, and routesto other nodes); and providing information to NMS 1175 includinginformation regarding each of nodes A-C 1200, 1300, 1302 or any othernode (e.g., a router) in network environment 1000.

Network Management System (NMS) 1175 may be embodied by one or more dataprocessors. NMS 1175 may function to infer one or more services onnetwork 1000 and to manage network 1000. One of ordinary skill in theart would recognize that network management includes the execution ofone or more functions for controlling, planning, allocating, deploying,coordinating, and/or monitoring the resources of a network. Moreover,when a plurality of INEs are present in a network, NMS 1175 mayaggregate information provided by the INEs and use that aggregateinformation to infer one or more services on the network. A service(e.g. an inferred service) may correspond to a virtual private networkbetween nodes, such as node A 1200 and node B 1300. NMS 1175 may be ableto infer that one or more virtual private network services exist betweennodes 1200 and 1300 by, for example, detecting route targets exported bynode A 1200 and/or node B 1300. See for example RFC-2547, E. Rosen etal., The Internet Society (1999), “BGP/MPLS VPNs,” that describes routetargets and BGP/MPLS (Border Gateway Protocol/Multiprotocol LabelSwitching) VPNs (draft-ieff-I3vpn-rfc2547bis-01.txt, E. Rosen et al.,The Internet Society, September 2003, “BGP/MPLS IP VPNs). In addition tolayer-3 type VPNs, such as BGP/MPLS VPNs, other types of VPNs may byinferred including, for example, layer-2 VPNs.

FIG. 2 depicts a portion of network environment 1000 in greater detail.In particular, node A 1200 and node B 1301 are each depicted as arouter, and communication channel 1120 is depicted as an InternetProtocol (IP) network, such as the Internet.

Node A 1200 (labeled PE Router A) may be embodied as a router, such as aProvider Edge (PE) router configured with BGP/MPLS (Border GatewayProtocol/Multiprotocol Label Switching) VPNs. One of ordinary skill inart will recognize that commercially available software may beconfigured on node A to implement tunnels and corresponding BGP/MPLSVPNs. Moreover, PE Router 1200 may include interface A 201 to a CustomerEdge device (CEA) 2060, interface B 202 to customer edge device (CEB)2061, interface C 203 to INE 1170, and interface D 204 to network 1120.The interfaces may be embodied as any type of physical interfaceincluding, for example, an Ethernet interface or a wireless interface.Moreover, interface C 203 and INE 1170 may be connected by a link 1121which may be a direct connection or a network, such as network 1120. Inaddition, Customer Edge devices 2060-2066 may be embodied as any type ofcustomer device, such as a Customer Edge (CE) router (see, e.g.,RFC-2547) or any other edge device serving as an interface between acustomer and a network. Node B 1301 (labeled PE Router B) may beconfigured in a manner similar to PE Router A 1200.

FIG. 3 is a flowchart with exemplary steps for determining theperformance of a node (or the interfaces therein). Referring to FIGS. 2and 3, INE 1170 may configure an interface, such as interface C 203, tohave a similar QoS profile as customer interface A 201, which is the“interface under test” (step 310). INE 1170 may then send packetsthrough the configured interface C 203. In some embodiments, thegenerated packets sent through interface C 203 may be of the same type(e.g., header, protocol(s), and/or size) (step 320) as packets typicallyreceived at interface A 201, such that the generated packets areinjected into a tunnel (not shown) between PE Routers A and B 1200,1301. INE 1171 may then receive the packets from INE 1170, interface C203, network 1120, and PE Router 1301. INE 1171 may then determine oneor more performance parameters based one the received packets (step330). For the interface under test, INE 1171 may determine, based on thereceived packets, performance parameters, such as latency, jitter, andpacket loss. If other interfaces require testing, INE 1170 may thenrepeat steps 310-330 for each of those interfaces (step 340). With theabove general description, the following describes steps 310-340 ingreater detail.

In one embodiment, before beginning steps 310-340, a user of a networkmanagement system, such as NMS 1175, may select one or more virtualprivate networks (VPNs), such as BGP/MPLS VPNs, to monitor and testperformance. In some instances, a user may be prompted to select aspecific customer, a customer's VPNs, a link (or connection), and/orspecific services for that customer. For example, a user may selectcustomer A's Voice over IP (VoIP) traffic only between New York and LosAngeles. Moreover, the user may be prompted to select how frequently thespecific customer VPNs should be tested, the specific parameters totest, and/or any thresholds for generating alarms. The user's profilesfor testing can be saved in the INEs or, alternatively, NMS 1175.

To configure an interface, such as interface C 203, to have a similarQoS profile as the interface under test, which in this case is customerinterface A 201 (step 310), INE 1170 may issue a query to PE Router A1200. In this example, PE router A serves as the head-end (or origin) ofa tunnel from PE Router A 1200 to PE Router B 1301. By querying PERouter A 1200, INE 1170 may obtain the QoS profile associated withinterface A 201 including, for example, the associated class(es) ofservice, queue priority, and/or drop precedence. One of ordinary skillin the art would recognize that such profile information can be groupedin many commercially available routers as the “QoS Profile,” anddifferent profiles associated with different interfaces may beidentified uniquely with a name, a number, or other like identifier. Insuch a case, INE 1170 may simply retrieve the interface A 201 QoSProfile identifier and configure interface C 203 with the same QoSprofile.

In some embodiments, INE 1170 may query PE Router A 1200 by readingseveral MIB (Management Information Base) tables using the SNMP (SimpleNetwork Management Protocol) or using a Command Line Interface (CLI). Insome other embodiments, INE 1170 may determine the QoS profile ofinterface A 201 by discovering such information, as described inco-pending U.S. Application U.S. patent application Ser. No. 10/845,517entitled “SYSTEMS AND METHODS FOR INFERRING SERVICES ON A NETWORK”[Attorney Docket No. 09278-0001]. In such discovery instances, NMS 1175may store QoS information and any updates (changes and refreshes),allowing INE 1170 to simply read the QoS profile for interface A 201from QoS information stored in NMS 1175. The QoS profile information maythen be configured at interface C 203 (or router 1200) by setting theinterface using SNMP, CLI, or the like.

To send packets (step 320), INE 1170 may send packets through link 1121and interface C 203 with the same (or similar) characteristics aspackets received at interface A 201. For example, if interface A 201 hasa predetermined QoS Profile Identifier named “Platinum 1” associatedwith VoIP traffic at PE Router A 1200, INE 1170 may generate packetsthat are of the same (or similar) type (in this example VoIP typepackets) including header field(s), size, and/or protocol(s.) INE 1170may then send the generated packets to interface C 203. At interface C,PE Router A applies the Platinum 1 QoS profile and any associated rules(also known as tunnel injection criteria) that dictate how, when, andwhat traffic should be allowed access to a BGP/MPLS tunnel originatingat PE Router A 1201 and terminating at PE Router B 1301.

One of ordinary skill in the art would recognized that packets receivedat interface A 201 may be packets from customer 2061 with variousdestinations including, e.g., destinations 2064 and 2066.

In one embodiment, INE 1170 sets, based on the QoS profile and anycorresponding injection criteria for the tunnel, one or more of thefollowing header fields in the packets generated by the INE 1170: (1) aDSCP (Differentiated Services Code Point) value that is indicative ofthe incoming priority of the packet; (2) an IP protocol number (e.g.,based on the IP protocol, PE Router A 1200 may treat packetsdifferently); (3) an application protocol number (if PE Router A 1200 iscapable of treating different applications differently); and (4) sourceand destination IP addresses and/or ports. Returning to the aboveexample, the injection criteria would include rules that would allow ordeny access to a BGP/MPLS tunnel from PE Router A 1200 to PE Router B1300 based on, for example, one or more of the values associated with(1)-(4).

To determine performance parameters (step 330), INE 1171 receives thepackets from interfaces 203 and 204, network 1120 (and the BGP/MPLStunnel therein), PE Router 1301, and link 1122. Based on the receivedpacket(s), INE 1171 will determine one or more performance parameters,such as latency, jitter, and/or packet loss. For example, if the packetgenerated by INE 1170 includes a time stamp, INE 1171 can measurelatency, jitter, and packet loss at INE 1171. Moreover, INE 1171 mayperform additional processing to remove the effects of link 1121 andlink 1122, as will be described in greater detail below with respect toFIG. 8. The determined one or more parameters represent the performanceof the interface under test, which in this case is interface A 201.

If other interfaces (e.g., interface B 202) are scheduled to be tested,INE 1170 then repeats steps 310-330 for those interfaces (step 340).Otherwise, the process ends.

Each of nodes A-C 1200, 1301, 1302, INEs 1170-1171, and NMS 1175 may beimplemented as a data processor, such as data processor 4000 depicted inblock diagram form at FIG. 4. Data processor 4000 may include a centralprocessing unit 4200, a storage module 4500, and/or an input/output(I/O) module 4300. In the case of nodes A-C, data processor 4000 mayinclude code, which configures CPU 4200 to function as a router or aswitch. Furthermore, the router or switch may represent one or morenodes on the network.

The I/O module 4300 may include one or more input/output (I/O) devicesincluding a display 4350, a keyboard, a mouse, an input storage device,and a network interface 4380. Network interface 4380 permits dataprocessor 4000 to communicate through a network, such as communicationchannel 1120. For example, network interface 4380 may be embodied as anEthernet network interface card or a wireless LAN interface card, suchas a card compatible with the IEEE 802.11 series of wireless LANstandards. In some embodiments, display 4350 is separate from dataprocessor 4000. For example, display 4350 may be provided on anotherdata processor connected remotely to data processor 4000.

Central processing unit 4200 may include, for example, one or more ofthe following: a central processing unit, a co-processor, memory,registers, and other processing devices and systems as appropriate.Moreover, unit 4200 (or associated memory) may include source code (notshown) that configures data processor to function as a router to routepackets, such as IP packets. Moreover, such code may include code toconfigure the router to function as a router in a VPN, such as aBGP/MPLS VPN, including associated PE nodes and CE nodes used inBGP/MPLS VPNs, (see, e.g., RFC-2547, “BGP/MPLS VPNs,”).

Storage module 4500 may be embodied with a variety of components orsubsystems capable of providing storage including, for example, a harddrive, an optical drive, a general-purpose storage device, a removablestorage device, and/or memory. Moreover, storage module 4500 may includeone or more of the following: network object information for each of thenodes of network 1000, inferred network objects, inferred services, QoSprofile information for one or more nodes, performance information forthe one or more nodes, and any other information associated with network1000.

Although CPU 4200 is generally described in terms of data processor4000, CPU 4200 may also be incorporated into any other data processingor communication device including, for example, a router, a switch, agateway, a bridge, and/or a network management system. For example, inone embodiment, each of nodes A-C 1200, 1301-1302 are embodied asrouters; INEs 1170-1171 are embodied as a data processor incorporatedinto a high performance core router; and NMS 1175 is embodied as a dataprocessor, such as a high performance work station (e.g., a SUN FireE25K Server or a SUN V12 80).

FIG. 5 depicts another exemplary flowchart with steps for determiningperformance consistent with another embodiment of the present invention.Referring to FIGS. 2 and 5, INE 1170 may determine which tunnels to testbased on information stored at NMS 1175 (step 5100), with the tunnelcorresponding to a service provided to a customer. Next, INE 1170 maydetermine a QoS profile for the customer's interface (e.g., interface A1201) by querying PE Router A 1200 (step 5200). INE 1170 may thenconfigure an interface (e.g., interface C 203) at PE Router 1200 to havea similar QoS profile as interface A 201, which is the interface undertest (step 5300). INE 1170 may also determine the injection criteria forthe determined QoS profile (step 5400). Specifically, packets receivedat an interface with the determined QoS profile are processed with oneor more rules (also referred to as “injection criteria”) that specifythe criteria for allowing packets to access a BGP/MPLS tunnel between PERouter A 1200 and PE Router B 1301. Next, INE 1170 generates packetsthat satisfy the determined injection criteria and then sends thegenerated packets to PE Router 1200 via link 1121 and interface C 203(step 5500). Based on an injection criteria, PE Router A 1200 sends thegenerated packets to a BGP/MPLS tunnel between PE Router A 1200 and PERouter B 1301. Specifically, only packets that satisfy the QoS profileand corresponding injection criteria will be allowed access to theBGP/MPLS tunnel. INE 1171 then receives the generated packet from INE1170, interface C 203, PE Router A 1200, network 1120, PE Router B 1301,and link 1122. INE 1171 may then initiate a test to determineperformance based on one or more packets received from INE 1170 (step5600). If there are other interfaces at PE Router A 1200, INE 1170 maythen test, using steps 5100-5600, those other interfaces (step 5700). Ifthere are other nodes, INE 1170 may then test, using steps 5100-5600,those other nodes and their corresponding interfaces (step 5800).Otherwise, processing is complete.

FIG. 6 depicts the exemplary network environment of FIG. 2 withadditional nodes. Network 1120 is depicted as one or more links 450-482.Moreover, INE 1170 is attached to the Ethernet interface of PE node D452.

Referring to FIG. 6, CEA represents a customer with traffic (e.g., VoIPpackets). Customer CEA 2060 may have a service level agreement (SLA)with a network service provider. The SLA enables the customer to accessa traffic-engineered tunnel(s) between PE node A 1200 and PE node B1301. Typically, such tunnels are shared across multiple customers(e.g., customers A and B 2060-2066) based on the agreed level of serviceassociated with each customer and on the type of traffic that originatesfrom each customer. For example, customer CEA 2060 may contract for“Platinum” level service with the network service provider. The PlatinumQoS level may specify performance parameters (e.g., availability, delay,and packet loss) sufficient to satisfy the customer's delay sensitiveVoIP voice traffic. On the other hand, the customer may contract for adifferent service level for other traffic, such as email, video, etc.For example, the customer may have a SLA that specifies a lower, bestefforts service (“Bronze” service) for email. Similarly, customer CEB's2061 may contract for “Platinum” level service for delay sensitivetraffic, such as Voice Over IP (VoIP) traffic. In this example, bothCEA′S VoIP traffic and CEB VoIP traffic may use the same tunnel betweenPE node A 1200 and PE node B 1301 since that tunnel has been engineeredto satisfy VoIP traffic.

FIG. 7 depicts network 6000 with a tunnel 7100, such as a BGP/MPLStunnel between PE node A 1200 to PE node B 1301. Referring to FIGS. 5and 7, INE 1170 may determine which tunnels to test based on informationstored at NMS 1175 (step 5100), with the tunnel representative of aservice provided to a customer. As noted above, CEA 2060 may have VoIPpacket traffic for routing from PE Router A 1200 to PE Router B 1301over tunnel 7100. Moreover, the VoIP traffic may represent a serviceprovided by a network service provider and guaranteed to satisfy a SLA,which specifies, inter alia, performance (e.g., availability, latency,packet loss, jitter, and the like).

Although INE 1170 may directly connect to PE Router A 1170 (as depictedin FIG. 2), FIG. 7 depicts a virtual connection (through a tunnel 7200)between INE 170 and PE Router A 1200. For example, INE 1170 mayestablish a virtual connection to PE outer A using a variety oftechniques including, for example, a GRE (Generic Routing Encapsulation,RFC-2784) protocol, IP encapsulation within IP (also referred to asIP-IP tunneling), a VLAN (Virtual Local Area Network), and ATM PVC(Asynchronous Transfer Mode Permanent Virtual Circuit). One of ordinaryskill in the art will recognize that commercial software and/or hardwareis available to establish such connections between nodes in a network.When GRE is used, INE 1170 may implement the Linux operating system withdifferent IP addresses as “aliases” of the main INE 1170 IP address sothat multiple GRE tunnels can be created between INE 1170 and PE RouterA 1200. Although the description made herein refers to the use of GREtunnel 7200, any other connection mechanism may be used insteadincluding VLAN mechanisms.

To compensate for any packet loss, latency, and/or jitter characteristicintroduced by the GRE tunnel 7200 from INE 1170 to PE Router A, in someembodiments two such tunnels 7200, 7201 are implemented to conduct aloop back test to characterize the GRE portion of the network. Thecharacterization enables INE 1171 to remove the jitter, packet loss,latency contributions of the GRE tunnel 7200 from the tunnel of interest7100.

INE 1170 may determine a QoS profile for the customer CEA 2060 at PERouter A 1200 by querying the router (step 5200) or reading the profileinformation from NMS 1175. INE 1170 may then configure another interfaceat PE Router A 1200 to have a similar (or the same) QoS profile ascustomer CEA′S interface (“interface under test”) (step 5300). INE 1170may also determine the injection criteria for the determined QoS profile(step 5400). In particular, the injection criteria at PE Router Aspecify the type of packets that are allowed access to tunnel 7100. Forexample, customer CEA's VoIP packets may be allowed access to tunnel7100, but email packets may be denied.

Next, INE 1170 generates packets (step 5500) that satisfy the determinedinjection criteria and sends the generated packets to PE Router A 1200via link 1121 and interface 203 (not shown). Returning to the aboveexample, INE 1170 may generate packets that are similar to VoIP packets(e.g., similar header, structure, and/or size). INE 1170 then sends thegenerated packets through GRE tunnel 7200 to PE Router A 1201. PE RouterA 1201 then applies its injection criteria to the received packets,which should allow the generated packets to be granted access to tunnel7100 (just like CEA's VoIP packets which are granted access to tunnel7100). When INE 1170 generates packets that are “similar” to packetsreceived at the interface under test from CEA, INE 1170 generatespackets that are similar with respect to the injection criteria. Forexample, if packets received at the interface under test are injectedinto tunnel 7100 solely based on a specific header field (e.g., a DSCPfield value), INE 1170 would generate packets that are similar withrespect to having at least the same header field as the interface undertest packets.

The injection criteria may use the DSCP bits (for IP packets), EXP (forMPLS), Layer 2 information (VLAN-ID, logical L2 interface, L2 priority,etc.), and/or Layer 3+ information (protocol numbers, ports, transportlayer status, etc.) to route a packet to a tunnel (or route) thatsatisfies the required (or specified) QoS for that packet. The injectioncriteria thus provide rules for packet selection and injection on to aroute, such as a tunnel.

In some embodiments, a service provider may define three levels of QoS.The three service levels may consist of Best Efforts (BE), ExpeditedForwarding (EF), and Assured Forwarding (AF). Specifically, IP routingtraffic may receive BE service, voice may receive EF service, andvideo/multimedia signaling data and priority data may receive AFservice.

For BE, a service provider may specify a default injection criteria thatroutes traffic to predetermined path(s), such as a BGP/MPLS tunnel.Moreover, the service provider may establish the path by specifying orconfiguring one or more of the following: rate (bandwidth), depth(available buffer space in a queue), Rmax (queue length at which thereis a 100% probability of dropping a packet), peak rate (peak rate for alink), minimum policed unit (see, e.g. RFC-2212, “Specification ofGuaranteed Quality of Service,” S. Shenker, September 1997), Maximumpacket size (as configured or a default if not configured at therouter); R.sub.min (queue length at which there is a 0% probability ofdropping a packet), Slope (value used to compute drop probabilitybetween R.sub.min and R.sub.max), and a packet discard flag. For EF, aservice provider may define another set of tunnels for packetssatisfying the following injection criteria: EXP, DSCP, ILM (IncomingLabel Map), VRF, IP Protocol (L3+), etc. In the case of AF, a serviceprovider may define yet another set of tunnels for packets satisfyingother injection criteria values. Like the BE case, a service providermay establish the EF and AF paths to have specific parameters, such asrate, depth, etc.

Returning to packet generation step 550, PE Router B 1301 receives thegenerated packets from tunnel 7100 and routes those packets to GREtunnel 7204 and INE 1171. INE 1171 may then initiate tests of thereceived packet(s) to determine performance (step 5600). Moreover, inone embodiment, INE 1171 removes the packet loss, jitter, and latencyeffects of the GRE tunnels 7204 and 7200, so that the determinedperformance measurements represent only tunnel 7100.

One way to correct for the GRE tunnel portion 7200 is to use thetraditional “ping” protocol utility (from the INE to the PE) on the GRETunnel 7200 and use the results to correct for the error introduced bythe GRE tunnel 7200. Another ping can be performed over GRE tunnel 7204.The results of the ping tests, which provide time to traverse thetunnels, can be used to remove the effects of each of tunnels 7200 and7204. A more accurate approach is to use a loop back (also referred toas a second tunnel approach). For example, to correct for GRE tunnel7200, tunnel 7201 is established, and to correct for tunnel 7204, tunnel7203 is established, as shown in FIG. 7.

FIG. 8 depicts the tests performed by INE 1170 and 1171 to reduce (ifnot eliminate) the effects of GRE tunnels 7200 and 7204. Since 7200 and7204 are not part of the path (i.e., tunnel 7100) for the interface ofunder test, the jitter, latency, and packet loss effects of GRE tunnels7200 and 7204 should be removed from performance calculations made forthe interface under test. In one embodiment, INE 1171 determines thetime T1, which represents the end-to-end latency (time) measured betweenINE 1170 (as source) to INE 1171 (as destination). INE 1170 thendetermines time T2 by performing a loop back test, sending one or morepackets (with time stamps) to tunnel 7200, PE Router A 1200, andreturning on tunnel 7201. Meanwhile, INE 1171 determines time T3 byperforming a loop back test, sending one or more packets (with timestamps) to tunnel 7203, PE Router B 1301, and returning on tunnel 7204.

Next, INE 1171 determines the value of “12” which represents the latencybetween PE Routers A and B. In one embodiment, the value of 12 isdetermined based on the following equations:

I.sub.1+I.sub.2+I.sub.3=T.sub.1   Equation (1)

and

I.sub.2=T.sub.1−(I.sub.1+I.sub.3)   Equation (2)

where I.sub.1 represents the latency between INE 1170 and PE Router A1200; I.sub.2 represents the latency between PE Router A 1200 and PERouter B 1301; I.sub.3 represents the latency between PE Router B 1301and INE 1171; and T.sub.1 represents, as noted above, the end-to-endlatency time measured between INE 1170 (as source) and INE 1171 (asdestination).

From the loop back tests above, the following equations can also beused:

I.sub.1+I.sub.1¹=T.sub.2   Equation (3)

and

I.sub.3+I.sub.3¹=T.sub.3   Equation (4);

where I.sub.3′ represents latency between router 1301 and INE 1171; andI.sub.2′ represents latency between router 1200 and INE 1700.

Moreover, if the following is assumed to be true:

I.sub.1.apprxeq.I.sub.1′

and

I.sub.3.apprxeq.I.sub.3′.

The equations for I.sub.1 and I.sub.3 can be determined as follows:

I.sub.1=T.sub.2/2

and

I.sub.3=T.sub.3/2   Equations (5) and (6).

Based on Equations 2, 5 and 6, the latency I.sub.2 of only tunnel 7100(excluding the effects of the GRE tunnels 7200-7204) can be determinedbased on the following equation:

I.sub.2=T.sub.1−(T.sub.2+T.sub.3)/2   Equation (7).

In some embodiments, the generated test packets are time stamped tofacilitate performance testing, as note above. In these cases, the timestamp may be applied at the INE 1170 or PE Router A 1200. To reduceunwanted latency and reduce indeterminism, the time stamp may be appliedto a packet at (or near) network interface 204 of PE Router A 1200rather than at INE 1170.

Furthermore, if a time stamp is affixed to one or more packets atperiodic intervals, the timing and packet loss can readily bedetermined. For example, if an INE generates a packet with acorresponding time stamp every one millisecond, the receiving INE candetermine if a packet is missing—representing a packet loss—and thetiming associated with the packet loss.

If there are other interfaces at PE Router A 201, INE 1170 may thentest, using steps 5100-5600, each of those other interfaces (step 5700).If there are other nodes, INE 1170 may virtually connect to each ofthose nodes and then test each of those nodes (e.g., PE E 453) usingsteps 5100-5600 and their corresponding interfaces (step 5800).

FIG. 9 depicts another exemplary flowchart with steps for determiningperformance consistent with another embodiment of the present invention.Referring to FIGS. 2 and 9, INE 1170 may determine which tunnelscorrespond to a customer based on customer information stored at NMS1175 (step 9100). For example, the customer information stored at NMS1175 may indicate that Customer A is connected to PE Routers A and B1200 and 1301 and there are tunnel(s) between the routers.

Next, INE 1170 may determine which one of the tunnels to test (step9200). The determination of which tunnel to test may be based oninformation stored in NMS 1175 or may be driven by an event, such as analarm, a failure, or degradation of network performance. Alternatively,the determination of which tunnel to test may be based on a schedule(e.g., hourly, daily, weekly, etc.), such as a user defined schedulestored in NMS 1175.

INE 1170 may determine a QoS profile for the customer's interface (e.g.,interface A 1201) by querying PE Router A 1200, and then configure theinterface (e.g., interface C 203) at PE Router 1200 to have a similarQoS profile (e.g., same rate, buffer size, etc.) as interface A 201,which is the interface under test (steps 9310-9410). Meanwhile, INE 1170may determine the injection criteria for the determined QoS profile, andthen generate packets (steps 9305-9405). The generated packets aredefined such that they should be treated by PE Router 1200 in a mannersimilar to the packets received from interface A 201, with, for example,the generated packets having similar (or the same structure) in terms ofheader and size. For example, the packets may have the same headerfields (DSCP, EXP, etc.) and protocols (e.g., protocol numbers), as thepackets received from the customer's interface A 201, the interfaceunder test.

When the configuration of interface C 203 and the generation of thepackets is complete (steps 9405-9410), INE 1170 may then initiate a testof the interface under test, which in this case is interface A 201, bysending one or more packets from INE 1170 to INE 1171 through interfaceC 203, PE Router A, interface D 204, network 1120, PE Router 1301, andlink 1122. If there are other tunnels to test, INE 1170 repeats steps9100-9700 (step 9800). Some of the other tunnels may be at nodes otherthan node 1200. Otherwise, processing is complete.

FIG. 10 depicts another exemplary network environment 10000 consistentwith the present invention. FIG. 10 includes a switch 10100. Switch10100 may be any type of switch, such as an ATM switch, an Ethernet(e.g., Gigabit Ethernet) switch, or a wireless switch interface. In FIG.10 switch 10100 serves as an interface between network 1120 and a secondnetwork (labeled local loop network) 10200. Network 10200 may beembodied in a manner similar to network 1120. Although network 10200 maybe considered part of the same overall network as network 1120, in FIG.10 functions as a separate network. For example, local loop network10200 may be a wireless network for providing local access to customers,a local exchange carrier (LEC) network for providing local access tocustomers, or cable television drops to homes which provide localnetwork access to customers.

When switch 10100 is present in network 1120, INE 1170 may connect to PERouter A 1200 through switch 10100. Moreover, when a test of a customerinterface fails or shows degraded performance, INE 1170 (or NMS 1175)may “sectionalize” the failure by determining the performance of switch10100. For example, if customer 2061 is having performance problems(e.g., cannot access customer 2604), INE 1170 (or NMS 1175) may be ableto determine which section of the overall network is causing theproblem. If an SNMP query of switch 10100 determines that the switch isoperating correctly, INE 1170 may identify a cause within another“section” of network 1120. On the other hand, if an interface on switch10100 is not operating correctly (e.g., shows degraded performance interms of jitter, latency, or packet loss), INE 1170 may identify thecause as the local loop network 10200 “section” (or possibly the switch10100 itself). In some embodiments, the use of switch 10100 may alsoimprove latency measurements between INE 1170 and PE Router A 1200(e.g., where the link includes a more deterministic switch 10100).

Furthermore, in some embodiments, INEs 1171 and 1170 may emulate one ormore aspects of a CE router, as specified in RFC-2547 titled “BGP/MPLSVPNs.”

Systems and methods consistent with the present invention also includecomputer readable media that include program instruction or code forperforming various computer-implemented operations based on the methodsand processes of the invention. The media and program instructions maybe those specially designed and constructed for the purposes of theinvention, or they may be of the kind well known and available to thosehaving skill in the computer software arts. Moreover, the computerreadable media may be in the form of a signal on a carrier wave or maybe in the form of a storage media such as a disk. Examples of programinstructions include, for example, machine code, such as produced by acompiler, and files containing a high level code that can be executed bythe computer using an interpreter.

1. A method of testing a first interface of a node in a network based onsimulating the first interface at a second interface, said methodcomprising: determining a set of service parameters representative ofthe first interface; emulating the first interface based on configuringa second interface of the node in accordance with the determined set ofservice parameters representative of the first interface; sending,through the second interface, traffic that is representative of trafficreceived at the first interface; and determining one or more performanceparameters for the first interface based on the traffic sent through thesecond interface.
 2. The method of claim 1, wherein determining the setof service parameters of the first interface comprises determining atleast one of the following: a latency, a jitter, and a packet loss. 3.The method of claim 1, wherein determining the set of service parametersof the first interface comprises querying the node.
 4. The method ofclaim 1, wherein determining the set of service parameters of the firstinterface comprises determining the one or more service parameters ofthe first interface based on inferred services.
 5. The method of claim1, wherein sending traffic representative of traffic received at thefirst interface comprises determining one or more rules based on the oneor more service parameters, the one or more rules serving to route apacket from the node to a tunnel, when the packet satisfies at least oneof the one or more rules.
 6. A method of testing a first interface of afirst node in a network by a second node, said method comprising:receiving, at the second node, a set of service parametersrepresentative of the first interface of the node; receiving, at thesecond node, information indicating traffic that is received at thefirst interface; sending, from the second node to the first node, a setof configuration commands for configuring a second interface of the nodeas a simulated version of the first interface; and sending, from thesecond node to the configured second interface at the first node,traffic that is representative of traffic received at the firstinterface.
 7. The method of claim 6, further comprising generating, atthe second node, one or more tunneling packets and sending the generatedone or more tunneling packets from the second node to the secondinterface of the first node, wherein the generated one or more tunnelingpackets are routed by the first node from the second interface to thetunnel as if the generated packets had been received at the firstinterface.
 8. The method of claim 7, wherein generating the one or moretunneling packets includes generating at least one of the one or moretunneling packets with a packet header that is based on a packet headerof another packet received at the first interface of the first node. 9.The method of claim 7, wherein generating the one or more tunnelingpackets includes generating at least one of the one or more tunnelingpackets with a payload type similar to another packet received at thefirst interface of the first node.
 10. The method of claim 6 furthercomprising generating a virtual path through the network to a third nodethat is different from the first and second node.
 11. A method fortesting a first interface of a first node in a network without sendingtraffic through the first interface, said method comprising: receiving,from the node, traffic that has been simulated through the firstinterface based on traffic sent through a second interface of the node,wherein the second interface is configured to simulate the firstinterface; and determining one or more parameters for the firstinterface based on the received traffic that has been simulated.
 12. Themethod of claim 11, wherein determining the set of service parameters ofthe first interface comprises determining at least one of the following:a latency, a jitter, and a packet loss.
 13. The method of claim 11,wherein determining the set of service parameters of the first interfacecomprises determining the one or more service parameters of the firstinterface based on inferred services.
 14. The method of claim 11,wherein sending that is traffic representative of traffic received atthe first interface comprises determining one or more rules based on theone or more service parameters, the one or more rules serving to route apacket from the node to a tunnel, when the packet satisfies at least oneof the one or more rules.
 15. A network element in a network configuredto test a second element in the network, wherein the second elementcarries traffic via a first interface, said network element comprising:an interface communicably coupled to a second interface of the secondelement; and a processor configured to receive a set of serviceparameters, configure the second interface as a simulated version of thefirst interface based on the service parameters, and send, to the secondinterface, traffic representative of traffic received at the firstinterface.
 16. The network element of claim 15, wherein the networkelement is configured to receive the set of service parametersresponsive to a query of the second element.
 17. The network element ofclaim 15, wherein the network element is configured to receive the setof service parameters responsive to a query of a network managementsystem monitoring the second element.
 18. The network element of claim15, wherein the interface is communicably coupled to the secondinterface of the second element via a virtual path through the network.19. The network element of claim 15, wherein the interface iscommunicably coupled to the second interface of the second element viatunnel through the network.
 20. The network element of claim 19, whereinthe processor is configured to determine performance parameters at thefirst interface based on calculating a latency contribution of thetunnel through the network.